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Abstract. The UNICORE Grid-technology provides a seamless, secure 
and intuitive access to distributed Grid resources. In this paper we 
present the recent evolution from project results to production Grids. 
At the beginning UNICORE was developed as a prototype software in 
two projects funded by the German research ministry (BMBF). Over the 
following years, in various European-funded projects, UNICORE evolved 
to a full-grown and well-tested Grid middleware system, which today is 
used in daily production at many supercomputing centers worldwide. 
Beyond this production usage, the UNICORE technology serves as a 
solid basis in many European and International research projects, which 
use existing UNICORE components to implement advanced features, 
high level services, and support for applications from a growing range of 
domains. In order to foster these ongoing developments, UNICORE is 
available as open source under BSD licence at SourceForge, where new 
releases are published on a regular basis. This paper is a review of the 
UNICORE achievements so far and gives a glimpse on the UNICORE 
roadmap. 



1 Introduction 

End of 1998 the concept of "Grid computing" was introduced in the monograph 
"The Grid: Blueprint for a New Computing Infrastructure" by I. Foster and C. 
Kesselman pp. Two years earlier, in 1997, the development of the UNICORE 
- Uniform Interface to Computing Resources - system was initiated to enable 
German supercomputer centers to provide their users with a seamless, secure, 
and intuitive access to their heterogeneous computing resources. Like in the case 
of the Globus Toolkit® UNICORE was started before "Grid Computing" 
became the accepted new paradigm for distributed computing. 

The UNICORE vision was proposed to the German Ministry for Education 
and Research (BMBF) and received funding. A first prototype was developed in 
the UNICORE^ project The foundations for the current production version 

^ funded in part by BMBF grant 01 IR 703, duration: August 1997 - December 1999 



were laid in the follow-up project UNICORE Plus^ which was successfully 
completed in 2002. Since then UNICORE was used in operation at German su- 
percomputing centers and became a solid basis for numerous European projects. 
In this paper we will describe the evolution of UNICORE from a prototype soft- 
ware developed in research projects to a Grid middleware used today in the daily 
operation of production Grids. 

Although already set out in the initial UNICORE project proposal in 1997, 
the goals and objectives of the UNICORE technology are still valid: 

— Foremost, the aim of UNICORE is to hide the rough edges resulting from 
different hardware architectures, vendor specific operating systems, incom- 
patible batch systems, different application environments, historically grown 
computer center practices, naming conventions, file system structures, and 
security policies - just to name the most obvious. 

— Equally, security is a constituent part of UNICORE's design relying on X.509 
certificates for the authentication of users, servers, and software, and the 
encryption of the communication over the internet. 

— Finally, UNICORE is usable by scientists and engineers without having 
to study vendor or site-specific documentation. A Graphical User Interface 
(GUI) is available to assist the user in creating and managing jobs. 

Additionally, several basic conditions are met by UNICORE: the Grid mid- 
dleware supports operating systems and batch systems of all vendors present at 
the partner sites. In 1997 these were for instance large Cray T3E systems, NEC 
and Hitachi vector machines, IBM SP2s, and smaller Linux clusters. Nowadays 
the spectrum is even broader, of course with modern hardware, such as IBM 
p690 systems. The deployed software has to be non-intrusive, so that it does 
not require changes in the computing centers hard- and/or software infrastruc- 
ture. Maintaining site autonomy is still a major issue in Grid computing, when 
aspects of acceptability and usability in particular from the system adminis- 
trator's point of view are addressed. In addition to UNICORE's own security 
model, site-specific security requirements (e. g. firewalls) are supported. 

Near the end of the initial funding period of the UNICORE Plus project, a 
working prototype was available, which showed that the initial concept works. 
By combining innovative ideas and proven components over the years, this first 
prototype evolved to a vertically integrated Grid middleware solution. 

The remainder of this paper is structured as follows. In section 2 the ar- 
chitecture of UNICORE and its core features are described. European fimded 
projects, which use UNICORE as a basis for their work are described in Section 
3, and in Section 4 the usage of UNICORE in production is described. Section 
5 gives an outlook on the future development of UNICORE. The paper closes 
with conclusions and acknowledgements. 



^ funded in part by BMBF grant 01 IR 001 A-D, duration: January 2000 - December 
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2 The Architecture of UNICORE 



Figure shows the layered Grid architecture of UNICORE consisting of user, 
server and target system tier |S] . The implementation of all components shown is 
realized in Java. UNICORE meets the Open Grid Services Architecture (OGSA) 
|Sj concept following the paradigm of 'Everything being a Service'. Indeed, an 
analysis has shown that the basic ideas behind UNICORE already realizes this 
paradigm |7I8| . 



2.1 User Tier 

The UNICORE Client provides a graphical user interface to exploit the entire 
set of services offered by the underlying servers. The client communicates with 
the server tier by sending and receiving Abstract Job Objects (AJO) and file 
data via the UNICORE Protocol Layer (UPL) which is placed on top of the 
SSL protocol. The AJO is the realization of UNICORE's job model and central 
to UNICORE's philosophy of abstraction and seamlcssness. It contains plat- 
form and site independent descriptions of computational and data related tasks, 
resource information and workflow specifications along with user and security 
information. AJOs are sent to the UNICORE Gateway in form of serialized and 
signed Java objects, followed by an optional stream of bytes if file data is to be 
transferred. 
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Fig. 1. The UNICORE architecture. 



The UNICORE client assists the user in creating complex, interdependent 
jobs that can be executed on any UNICORE site (Usite) without requiring any 
modifications. A UNICORE job, more precisely a job group, may recursively 
contain other job groups and/or tasks and may also contain dependencies be- 
tween job groups to generate job workflows. Besides the description of a job as a 
set of one or more directed a-cyclic graphs, conditional and repetitive execution 
of job groups or tasks are also included. For the monitoring of jobs, their status 
is available at each level of recursion down to the individual task. Detailed log 
information is available to analyze potential error conditions. At the end of the 
execution of the job it is possible to retrieve the stdout and stderr output of the 
job. Data management functions like import, export, and transfer are available 
through the GUI as explicit tasks. This allows the user to specify data transfer 
from one target system to another (e.g. for workflows), from or to the local 
workstation before or after the execution of a job, or to store data permanently 
in archives. 

The previously described features already provide an effective tool to use 
resources of different computing centers both for capacity or capability comput- 
ing, but many scientists and engineers use application packages. For applications 
without a graphical user interface, a tool kit simplifies the development of a cus- 
tom built UNICORE plug-in. Over the years many plug-ins were developed, so 
that plug-ins already exist for many standard scientific applications, as c. g. for 
CPMD (Car-Parrinello Molecular Dynamics) jlj, Fluent or MSC Nastran. 

2.2 Server Tier 

The server tier contains the Gateway and the Network Job Supervisor (NJS). 
The Gateway controls the access to a Usite and acts as the secure entry point 
accepting and authenticating UPL requests. A Usite identifies the participating 
organization (e. g. a supercomputing center) to the Grid with a symbolic name 
that resolves into the URL of the Gateway. An organization may be part of 
multiple Grids offering the same or different resources to different communities. 
The Gateway forwards incoming requests to the underlying Network Job Super- 
visor (NJS) of a virtual site (Vsite) for further processing. The NJS represents 
resources with a uniform user mapping scheme and no boundaries like firewalls 
between them. 

A Vsite identifies a particular set of resources at a Usite and is controlled by 
a NJS. A Vsite may consist of a single supercomputer, e. g. a IBM p690 System 
with LoadLeveler, or a Linux cluster with PBS as resource management system. 
The flexibility of this concept supports different system architectures and gives 
the organization full control over its resources. Note that, there can be more 
than one Vsite inside each USite as depicted in Figure H 

The NJS is responsible for the virtualization of the underlying resources by 
mapping the abstract job on a spcciflc target system. This process is called "in- 
carnation" and makes use of the Incarnation Database (IDB). System-specific 
data are stored in the IDB describing the software and hardware infrastruc- 
ture of the system. Among others, the available resources like software, incar- 



nation of abstract commands (standard UNIX command like rm, cp, ...) and 
site-specific administrative information are stored. In addition to the incarnation 
the NJS processes workflow descriptions included in an AJO, performs pre- and 
post-staging of files and authorizes the user via the UNICORE User Database 
(UUDB). Typically the Gateway and NJS are running on dedicated secure sys- 
tems behind a firewall, although the Gateway could be placed outside a firewall 
or in a demilitarized zone. 

2.3 Target System Tier 

The Target System Interface (TSI) implements the interface to the underlying 
supercomputer with its resource management system. It is a stateless daemon 
running on the target system and interfacing with the local resource manager 
realized either by a batch system like PBS ^01 or CCS a batch system 
emulation on top of e. g. Linux, or a Grid resource manager like Globus' GRAM 

2.4 Single Sign-On 

The UNICORE security model relies on the usage of permanent X.509 certifi- 
cates issued by a trusted Certification Authority (CA) and SSL based communi- 
cation across 'insecure' networks. Certificates are used to provide a single sign-on 
in the client. The client unlocks the user's keystore when it is first started, so 
that no further password requests are handed to the user. All authentication 
and authorization is done on the basis of the user certificate. At each UNICORE 
site user certificates are mapped to local accounts (standard UNIX uid/gid), 
which may be different at each site, due to existing naming conventions. The 
sites retain full control over the acceptance of users based on the identity of 
the individual ~ the distinguished name - or other information that might be 
contained in the certificate. UNICORE can handle multiple user certificates, i. e. 
it permits a client to be part of multiple, disjoint Grids. It is also possible to 
specify project accounts in the client allowing users to select different accounts 
for different projects on one execution system or to assume different roles with 
different privileges. 

The private key in the certificate is used to sign each job and all included sub- 
jobs during the transit from the client to sites and between sites. This protects 
against tampering while the job is transmitted over insecure internet connections 
and it allows to verify the identity of the owner at the receiving end, without 
having to trust the intermediate sites which forwarded the job. 

3 UNICORE Based Projects 

During the evolutionary development of the UNICORE technology, many Eu- 
ropean and international projects have decided to base their Grid software im- 
plementations on UNICORE or to extend the growing set of core UNICORE 



functions with new features specific to their project focus. The goals and ob- 
jectives of projects using UNICORE arc not limited to the computer science 
community alone. Several other scientific domains such as bio-molecular engi- 
neering or computational chemistry are using the UNICORE technology as the 
basis of their work. In the following we present short overviews of goals and 
objectives of UNICORE-based projects and describe additional functions and 
services contributed to the UNICORE development. 

3.1 EUROGRID Application Testbed for European Grid 
Computing 

In the EUROGRID'^ project jJJ ^ Grid network of leading European High 
Performance Supercomputing centers was established. Based on the UNICORE 
technology application-specific Grids were integrated, operated and demonstrated: 

— Bio-Grid for biomolecular science 

— Meteo-Grid for localized weather prediction 

— CAE-Grid for coupling applications 

— HP C- Grid for general HPC end-users 

As part of the project, the UNICORE software was extended by an efficient 
data transfer mechanism, resource brokerage mechanisms, tools and services for 
Application Service Providers (ASP), application coupling methods, and an in- 
teractive access feature |15| . Efficient data transfer is a important issue, as Grids 
typically rely on public parts of Internet connections. The available limited band- 
width has to be used efficiently to reduce the transfer time and the integrity of 
the transferred data has to be maintained, even if the transfer is interrupted. 
Depending on the application domain, additional security and confidentiality 
concerns need to be considered. This UNICORE high performance data trans- 
fer also uses X.509 certificates for authentication and encryption. To achieve 
not only a fast and secure transfer of data, but also high-performance capabil- 
ities, network Quality of Service (QoS) aspects, overlapping of streamed data 
transfers, and packet assembling and compression techniques are included. 

In order to optimize the selection of resources - either done by the users man- 
ually or by a metascheduler automatically - resource brokerage mechanisms and 
detailed resource description abilities are important. Within the EUROGRID 
project, mechanisms were added to UNICORE, which allow users to specify 
their jobs in an abstract way improving the overall resource selection and ac- 
counting. In particular for the benefit of the industrial user aspects of security, 
convenience, and cost efficiency were addressed. To this end, the already ex- 
isting security concepts of UNICORE were thoroughly evaluated and assessed 
as being adequate, hence no additional development had to be done. The task 
of the developed resource broker is to match the abstract specification of the 
users jobs and their requirements with the available resources in the Grid. The 

^ funded in part by EC grant 1ST- 1999-20247, duration: November 2000 - January 
2004 



resource broker reports the best match back to the user incKiding an estimate 
of the costs, which than allows the user to assign the appropriate resources to 
the job. For the suppliers of Grid resources (e. g. supercomputing centers) the 
resource broker allows to specify information about computational resources, 
architectures, processing power, storage and archiving facilities, post-processing 
facilities like visualization equipment, available software packages, and security 
guarantees. All this data is enhanced by billing information. 

Supercomputing centers converge from pure providers of raw supercomput- 
ing power to Application Service Providers (ASP) running relevant scientific 
applications. For accounting and billing purposes the ASP needs to know the 
exact resources consumed by each customer in each run. For measuring the usage 
of supercomputers standard mechanisms provided by the resource management 
and operating system can be used, but measuring the usage of licenses requires 
a sophisticated approach. For some applications, c. g. from the Computer Aided 
Engineering (CAE) domain, this includes a connection to the applications li- 
cence manager. Establishing a link to the above mentioned resource broker is 
required to influence their decisions. 

For solving complex problems applications from different domains, e. g. fluid- 
structure or electromagnetism-structure, need to be coupled. This is established 
by using the EUROGRID resource broker functionality and combining it with 
the available Metacomputing functionality developed in the UNICORE Plus 
project (cf. Section^; which allows different schedulers of compute and appli- 
cation resources to cooperate. Finally, an interactive access to control and steer 
running application is needed for many scientific applications. The interactive 
use includes an interactive shell to actually login to computing resources using 
the UNICORE technology and security infrastructure. 

EUROGRID used the UNICORE technology to provide the above described 
services and functionalities by developing new components. After the project 
ended, the developed components were revised and useful additions to the core 
UNICORE functions are now part of the available UNICORE software. 

3.2 GRIP Grid Interoperability Project 

Grid computing empowers users and organizations to work effectively in an 
information-rich environment. Different communities and application domains 
have developed distinct Grid implementations some based on published open 
standards or on domain and community specific features. GRIP^ JHI h^id the 
objective to demonstrate that the different approaches of two distinct grids can 
successfully complement each other and that different implementations can in- 
teroperate. Two prominent Grid systems were selected for this purpose: UNI- 
CORE and Globus"'''^ |17|. a toolkit developed in the United States. In contrast 
to UNICORE, Globus provides a set of APIs and services which requires more in- 
depth knowledge from the user. Globus is widely used in numerous international 
projects and many centers have Globus installed as Grid middleware. 



" funded in part by EC grant IST-2001-32257, duration: January 2002 - February 2004 



The objectives of GRIP were: 

— Develop software to enable the interoperation of independently developed 
Grid solutions 

— Build and demonstrate prototype inter-Grid applications 

— Contribute to and influence international Grid standards 

During the runtime of the GRIP project the Open Grid Service Architecture 
was proposed by the Global Grid Forum (GGF) ^Hl- The arrival of OGSA also 
was an opportunity to influence the standards directly which were to be created 
and to start developments that allow UNICORE to interoperate not only with 
Globus but with services on the Grid in general, once the definition of the services 
and their interfaces became mature. OGSA did not change the overall objectives 
of GRIP; however, it influenced directly some of the technical results. 

A basic requirement of GRIP was that the Grid interoperability layer should 
not change the well-known UNICORE user environment. As developers from 
both communities cooperated in the GRIP project, this goal was reached with 
only little changes of the UNICORE server components and no changes of the 
Globus Toolkit. This was achieved by the development of the so called Globus 
Target System Interface (Globus TSI), which provides UNICORE-access to com- 
putational resources managed by Globus. The Globus TSI was integrated into a 
heterogeneous UNICORE and Globus testbed. 

To achieve the main objective of GRIP, the interoperability between UNI- 
CORE and Globus and initial OGSA services, the following elements had to be 
implemented: 

— The interoperability layer between UNICORE and Globus Version 2 

— The interoperability layer between UNICORE and Globus Version 3 

— The Access from UNICORE to simple Web services as a first step towards 
full integration of Web services 

— The Interoperability of the certificate infrastructures of UNICORE and Globus 

— A resource broker capable of brokering between UNICORE and Globus re- 
sources 

— The Ontology of the resource description on an abstract level 

In GRIP, two important application areas were selected to prove that the 
interoperability layers work as specified: 

— Bio-molecular applications were instrumented in such a way that they are 
Grid-aware in any Grid environment and capable to seamlessly use UNI- 
CORE and Globus managed resources. The techniques developed in GRIP 
were designed and implemented in a generalized way to ensure that they can 
be used in other application domains as well. 

— A meteorological application, the Relocatable Local Model (RLM), was de- 
composed in such a way that the components could execute on the most 
suitable resources in a Grid, independent of the middleware. 



The results of the GRIP project are important for understanding general 
interoperability processes between Grid middleware systems. The experience and 
knowledge of the GRIP partners allowed to work in many relevant areas within 
GGF, like security, architecture, protocols, workflow, production management, 
and applications, and to influence the work in GGF. 

3.3 OpenMolGRID Open Computing Grid for Molecular Science 
and Engineering 

The OpenMolGRID^ project was focused on the development of Grid en- 
abled molecular design and engineering applications. In silico testing |20| has 
become a crucial part in the molecular design process of new drugs, pesticides, 
biopolymers, and biomaterials. In a typical design process O(IO^) to O(IO^) can- 
didate molecules are generated and their feasibility has to be tested. It is not eco- 
nomical to carry out experimental testing on all possible candidates. Therefore, 
computational screening methods provide a cheap and cost effective alternative 
to reduce the number of candidates. Over the years Quantitative Structure Ac- 
tivity/Property Relationship (QSAR/QSPR) methods have been shown to be 
reliable for the prediction of various physical, chemical, and biological activities 

m 

QSPR/QSAR relies on the observation that molecular compounds with sim- 
ilar structure have similar properties. For each specific application a set of 
molecules is needed for which the target property is known. This requires search- 
ing globally distributed information resources for appropriate data. For the pur- 
pose of exploring molecular similarity, descriptors are calculated from the molec- 
ular structure. Thousands of molecular descriptors have been proposed and are 
used to characterize molecular structures with respect to different properties. 
Their calculation puts high demands on computer resources and requires high- 
performance computing. 

Based on this complex application the objectives of the OpenMolGRID project 
were defined as: 

— Development of tools for secure and seamless access to distributed informa- 
tion and computational methods relevant to molecular engineering within 
the UNICORE frame 

— Provision of a realistic testbed and reference application in life science 

— Development of a toxicity prediction model validated with a large experi- 
mental set 

— Provision of design principles for next generation molecular engineering sys- 
tems. 

In particular this included to use UNICORE to automatize, integrate, and speed- 
up the drug discovery pipeline. 

^ funded in part by EC grant IST-2001-37238, duration: September 2002 - February 
2005 



The OpenMolGRID project addressed the objectives above by defining ab- 
straction layers for data sources (databases) and methods (appHcation software), 
and integrating all necessary data sources (e.g. ECOTOX |22]) and methods 
(e.g. 2D/3D Molecular Structure Conversion and Optimization, Descriptor Cal- 
culation, Structure Enumeration) into UNICORE. The project developed appli- 
cation specific user interfaces (plug-ins) and a mechanism to generate a complete 
UNICORE Job from an XML workflow specification. This so called Meta-Plug- 
in takes care of including all auxiliary steps like data format transformation and 
data transfers into the job, distributing data parallel tasks over available compu- 
tational resources, and allocating resources to the tasks. Thereby the molecular 
design process was significantly improved as the time to build QSAR/QSPR 
models, the probability for mistakes, and the variability of results was reduced. 
In addition a command line client (CLC) for UNICORE was developed to en- 
able the data warehouse to use Grid resources for its data transformation pro- 
cesses. The CLC offers the generation of UNICORE jobs from XML workflow 
description as well as the job submission, output retrieval, status query, and job 
abortion. The CLC consists of commands, an API, and a queuing component. 

Besides the technical achievements of OpenMolGRID and the added value 
for pharmaceutical companies its results will contribute to the standardization 
of QSAR models. 

3.4 VIOLA Vertically Integrated Optical Testbed for Large 
Applications 

The aim of the VIOLA® project [23 is to build up a testbed with the latest 
optical network technology (multi 10 Gigabit Ethernet links). The goals and 
objectives of VIOLA are: 

— Testing of new network components and network architectures 

— Development and testing of software for dynamic bandwidth management 

— Interworking of network technology from different manufacturers 

— Development and testing of new applications from the Grid and Virtual 
Reality (VR) domain 

The performance of the new network technology is evaluated with differ- 
ent scientific applications that need a very high network performance and net- 
work flexibility. UNICORE is used to build up the Grid on top of the hardware 
without taking fundamental software modifications. Only an interface to the 
meta-computer software library MetaMPICH needs to be integrated into 
UNICORE. Grid applications from the High Performance Supercomputing and 
Virtual Reality domain are enhanced for an optimized usage of the available 
bandwidth and the provided Quality of Service classes. In this context a Meta- 
Scheduler framework is developed, which is able to handle complex workflows 
and multi-site jobs by coordinating supercomputers and the network connecting 
them. 



® funded in part by BMBF grant 01AK605F, duration: May 2004 - April 2007 
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Fig. 2. The VIOLA Mcta-Schcdulcr architecture. 



viola's first generation Meta-Scheduler architecture focuses on the schedul- 
ing functionality requiring only minimal changes to the UNICORE system. As 
depicted in Figure |21 the system comprises the Agreement Manager, the Meta- 
Scheduler itself I^S], and a Meta-Scheduling plug- in (which is part of the client 
and not pictured separately). Before submitting a job to a Usite (cf. Section lT^ . 
the Meta-Scheduling plug-in and the Meta-Scheduler exchange the data neces- 
sary to schedule the resources needed. The Meta-Scheduler is then (acting as an 
Agreement Consumer in WS-Agreement terms contacting the Agreement 
Manager to request a certain level of service, a request which is translated by 
the Manager into the appropriate resource management system commands. In 
case of viola's computing resources the targeted resource management system 
is the EASY scheduler. Once all resources are reserved at the requested time the 
Mcta-Schcdulcr notifies the UNICORE Client via the Meta-Scheduling plug-in 
to submit the job. This framework will also be used to schedule the intercon- 
necting network, but potentially any resource can be scheduled if a respective 
Agreement Manager is implemented and the Meta-Scheduling plug-in generates 
the necessary scheduling information. The follow-on generation of the Meta- 
Scheduling framework will then be tightly integrated within UNICORE/GS (cf. 
Section EH). 

3.5 NaReGI National Research Grid Initiative 

The Japanese NaReGI project [27| includes the UNICORE technology as the ba- 
sic middleware for research and development. NaReGI is a collaboration project 
between industry, academia, and government. The goals and objectives are: 



— Establishment of a national Japanese research Grid infrastructure 

— Rcvitalization of the IT industry through commercialization of Grid middle- 
ware and strengthened international competitiveness 

— Dissemination of Grid environments throughout industry 

— Trailblazing the standardization of Grid technology 

— Cultivation of human resources specializing in IT technology for Grids 

Similar to the GRIP project (cf. Section 13) where an interoperability layer 
between UNICORE and Globus Toolkit 2 and 3 was developed, the NaReGI 
project plans to implement such a layer between UNICORE and Condor |28| . 
called UNICONDORE. This interoperability layer will allow to submit jobs from 
the UNICORE client to Condor pools and to use Condor commands to submit 
jobs to UNICORE managed resources. 

In the first phase of the NaReGI testbed UNICORE provides access to about 
3000 CPUs in total with approximately 17 TFlops of peak performance. It is 
expected to increase the integrated peak performance to 100+ TFlops by the 
end of the project in 2007. 

4 UNICORE in Production 

From its birth in two German BMBF-funded projects to its extensive use and 
further development in a variety of EU and BMBF research projects, the UNI- 
CORE technology ran through an evolutionary process transforming from an 
initial prototype software to a powerful production Grid middleware. 

4.1 UNICOREOSourceForge 

Since May 2004, the UNICORE technology with all its components is available 
as open source software under the BSD license. It can be downloaded from 
the SourceForge repository. Besides the core developers of UNICORE (namely 
Fujitsu Laboratories of Europe, Intel Germany and the Research Center Jiilich), 
there are numerous contributors from all over the world, e. g. Norway, Poland, 
China and Russia. The Web site [^Hl offers a convenient entry point for interested 
users and developers. In the download section the UNICORE software is bundled 
in different packages, e. g. the client package and individual packages for the 
different server components Gateway, NJS, TSI/IDB, UUDB (cf. Section 
and plug-ins. Until January 2005 more than 2800 downloads of UNICORE are 
counted. 

A tracker section linked on the Web site establishes a communication link 
to the core developer community. The corresponding mailing lists allow users 
to report bugs, to request new features, and to get informed about bug fixes 
or patches. For the announcement of new software releases a separate mailing 
list was created. The Grid team at the Research Center Jiilich is responsible 
for UNICORE@SourceForge. Its work includes coordinating and driving the de- 
velopment effort, and producing consolidated, stable, and tested releases of the 
UNICORE software. 



4.2 Production System on Jump 

Since July 2004 UNICORE is established as production software to access the su- 
percomputer resources of the John von Neumann-Institute for Computing (NIC) 
at the Research Center Jiilich. These are the 1312-processor IBM p690 cluster 
(Jump) 120], the Cray SVl vector machine, and a new Cray XDl cluster system. 
As an alternative to the standard SSH login, UNICORE provides an intuitive 
and easy way for submitting batch jobs to the systems. The academic and in- 
dustrial users come from all over Germany and from parts of Europe. The appli- 
cations come from a broad field of domains, e. g. astrophysics, quantumphysics, 
medicine, biology, chemistry, and climate research, just to name the largest user 
communities. A dedicated, pre-configured UNICORE client with all required 
certificates and accessible Vsites is available for download. This alleviates the 
installation and configuration process significantly. Furthermore, an online in- 
stallation guide including a certificate assistant, an user manual, and example 
jobs help users getting started. 

To provide the NIC-users with adequate certificates and to ease the process 
of requesting and receiving a certificate, a certificate authority (CA) was estab- 
lished. User certificate requests are generated in the client and have to be send 
to the CA. Since introduction of UNICORE at NIC, more than 120 active users 
requested a UNICORE user certificate. 

A mailing list serves as a direct link of the users to UNICORE developers 
in the Research Center Jiilich. The list allows to post problems, bug reports, 
and feature requests. This input is helpful in enhancing UNICORE with new 
features and services, in solving problems, identifying and correcting bugs, and 
influences new releases of UNICORE available at SourccForge. 

4.3 DEISA Distributed European Infrastructure for Scientific 
Applications 

Traditionally, the provision of high performance computing resources to re- 
searchers has traditionally been the objective and mission of national HFC cen- 
ters. On the one hand, there is an increasing global competition between Europe, 
USA, and Japan with growing demands for compute resources at the highest per- 
formance level, and on the other hand stagnant or even shrinking budgets. To 
stay competitive major investments are needed every two years an innovation 
cycle that even the most prosperous countries have difficulties to fund. 

To advance science in Europe, eight leading European HFC centers devised 
an innovative strategy to build a Distributed European Infrastructure for Sci- 
entific Applications (DEISA) The centers join in building and operating 
a tera-scale supercomputing facility. This becomes possible through deep inte- 
gration of existing national high-end platforms, tightly coupled by a dedicated 
network and supported by innovative system and grid software. The resulting 
virtual distributed supercomputer has the capability for natural growth in all 
dimensions without singular procurements at the European level. Advances in 
network technology and the resulting increase in bandwidth and lower latency 



virtually shrink the distance between the nodes in the distributed super-cluster. 
Furthermore, DEISA can expand horizontally by adding new systems, new ar- 
chitectures, and new partners thus increasing the capabilities and attractiveness 
of the infrastructure in a non-disruptive way. 

By using the UNICORE technology, the four core partners of the projects 
have coupled their systems using virtually dedicated 1 Gbit/s connections. The 
DEISA super-cluster currently consists of over 4000 IBM Power 4 processors and 
416 SGI processors with an aggregated peak performance of about 22 teraflops. 
UNICORE provides the seamless, secure and intuitive access to the super-cluster. 

The Research Center Jiilich is one of the DEISA core partners and is respon- 
sible for introducing UNICORE as Grid middleware at all partner sites and for 
providing support to local UNICORE administrators. 

All DEISA partners have installed the UNICORE server components Gate- 
way, NJS, TSI, and UUDB to access the local supercomputer resources of each 
site via UNICORE. Figure El shows the DEISA UNICORE configuration. For 
clarity only four sites are shown. At each site, a Gateway exists as an access 
to the DEISA infrastructure. The NJSs are not only registered to their local 
Gateway, but to all other Gateways at the partner sites as well. Local secu- 
rity measures like firewall configurations need to consider this, by permitting 
access to all DEISA users and NJSs. This fully connected architecture has sev- 
eral advantages. If one Gateway has a high load, access to the high performance 
supercomputers through DEISA is not limited. Due to the fully connected ar- 
chitecture, no single point of failure exists and the flexibility is increased. 

The DEISA partners operate different supercomputer architectures, which 
are all accessible through UNICORE. Initially all partners with IBM p690 clus- 
ters are connected to one large virtual supercomputer. In a second step other 
supercomputers of different variety are connected to DEISA, making the virtual 
supercomputer heterogeneous. UNICORE can handle this, as it is designed to 
serve such heterogeneous architectures in a seamless, secure, and intuitive way. 

In December 2004 a first successful UNICORE demonstration between the 
four DEISA core sites FZJ (Research Center Jiilich, Germany), RZG (Comput- 
ing Center Garching, Germany), CINECA (Italian Interunivcrsity Consortium, 
Italy) and IDRIS (Institute for Development and Resources in Intensive Scien- 
tific Computing, France) was given. Different parts of a distributed astrophysical 
application were generated and submitted with UNICORE to all four sites. 

The experience and knowledge of the researchers, developers, users, and ad- 
ministrators in working with UNICORE in the DEISA project on a large pro- 
duction platform will be used as useful input for future developments of the 
UNICORE technology. A close synchronization with the UniGrids project (cf. 
Section is foreseen. 

5 Future of UNICORE 

The current UNICORE software implements a vertically integrated Grid archi- 
tecture providing seamless access to various resources. Every resource is statically 




Fig. 3. The DEISA architecture. 



integrated into the UNICORE Grid by providing an interface to the appropriate 
resource manager. 

One of the benefits Web services will bring to Grid computing is the con- 
cept of loosely coupled distributed services. Merging the idea of "everything 
being a service" with the achievements of the Grid community led to Grid ser- 
vices, enabling a new approach to the design of Grid architectures. The adoption 
of XML and the drive for standardization of the Open Grid Service Architec- 
ture provide the tools to move closer to the promise of interoperable Grids. A 
demonstrator validated the correspondence of UNICORE's architectural model 
with the OGSA/OGSI (Open Grid Service Infrastructure approach, which 
encouraged the development of an OGSA/OGSI compliant UNICORE Grid ar- 
chitecture in the GRIP project (cf. Section IX^ . 

In UNICORE is examined for the evolution of a Grid system towards a 
service oriented Grid, primarily focussing on architectural concepts and models. 
Based on the current architecture and the enhancements provided by GRIP, 
first steps already integrate Web services into UNICORE. This included the 
provision of OGSI compliant port types parallel to the proprietary ones as well 
as the design of XML based protocols. This work was continued in the UniGrids 
project. 



As mentioned above the development of a Grid middleware is an contin- 
uous process of integrating new features, services, and adapting to emerging 
standards, and UNICORE is no exception. In the following we present new de- 
velopments, some technical details, and report on projects, which enhance the 
UNICORE technology to serve the demands of the Grid in the future |33| . 

5.1 UniGrids Uniform Interface to Grid Services 

The strength of the UNICORE architecture is well-proven as described above. 
The rapid definition and adoption of OGSA allow the UNICORE development 
community to re-cast and extend the concepts of UNICORE through the use 
of Web services technologies. The goal of the UniGrids^ project is to lift 
UNICORE on an architecture of loosely-coupled components while keeping its 
'end-to-end' nature. 

Thus, the integration of Web services techniques and UNICORE, which al- 
ready started in the GRIP project (cf. Scction lX^ . will continue in the UniGrids 
project. Interoperability, through adopting and influencing standards, form the 
philosophical foundation for UniGrids. The project aims to transform UNICORE 
into a system with interfaces that are compliant with the Web Services Resource 
Framework (WS-RF) [33] and that interoperate with other WS-RF compliant 
software components. 

Such an approach offers great advantages both for the ease of development 
of new components by aggregation of services and through the integration of 
non-UNICORE components into the standards-based infrastructure. 

In this sense, work is continuing in the following areas: 

— Development of a compliant WS-RF hosting environment used for publishing 
UNICORE job and file services as Web services. 

— Support of dynamic virtual organizations by enhancing the UNICORE se- 
curity infrastructure to allow different usage models such as delegation and 
collective authorization. 

— Development of translation mechanisms, such as resource ontologies, to in- 
teroperate with other OGSA compliant systems. Support for Grid economics 
by developing a Service Level Agreement (SLA) framework and cross-Grid 
brokering services. 

— Development and integration of generic software components for visualiza- 
tion and steering of simulations (VISIT device monitoring and control, 
and tools for accessing distributed data and databases. 

Applications from the scientific and industrial domain, like biomolecular and 
computational biology, geophysical depth imaging by oil companies, automotive, 
risk-management, energy, and aerospace are used to prove the developments in 
UniGrids. 

The development in the UniGrids project will lead to UNICORE/GS, which 
follows the architecture of OGSA through the standardization of WS-RF and 
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related work like e. g. the Web Services Notification technology |37j. The results 
will be made available under an open source BSD license. 

UNICORE/GS Web service technology, and in particular the WS-RF, forms 
the basis for the UNICORE/GS software. WS-RF is the follow-on to OGSI, but 
more in line with mainstream Web services architecture j2Hl ■ Based on this new 
technology, UNICORE/GS will retain its key characteristics of seamlessncss, se- 
curity, and intuitiveness from both the user and administrative perspective, but 
will be built on a service oriented framework. This means that there is a loosening 
of the coupling between the components of the system. UNICORE/GS keeps the 
classical UNICORE topology of Usites, each containing a number of Vsites, but 
provides a new framework for integrating other services and providing common 
infrastructure functionality as services. This has the implication that new ser- 
vices will be easily integrated into the UNICORE/GS environment. Conversely, 
UNICORE/GS will be well-prepared to make use of external services. 

The WS-RF technology is used to model core functionalities such as job 
submissions and file transfers as WS-Resources. These services are accessible 
via web service interfaces and thus establishing the UniGrids atomic services 
layer. This layer will be realized making extensive use of existing UNICORE 
server components. 

All services in a Usite are accessible through the UniGrids Gateway that 
provides a secure entrance into the UNICORE/GS infrastructure. The principal 
is exactly the same as for classic UNICORE, however, the Gateway now routes 
messages according to Web Services Addressing (WS-Addressing) (SHI ■ Authen- 
tication is based on transport level HTTPS security, although the intention is 
to move to Web Services Security ( WS-Security) 00] . Regarding authorized ac- 
cess to resources, the UNICORE User Database (UUDB) will be available as a 
service to other services in the Usite, and will form the basis for future work 
concerning virtual organizations and fine-grained authorization schemes. 

The underlying UniGrids atomic services layer will provide an excellent frame- 
work to deploy higher-level services such as co-allocation schedulers, workflow 
engines, and services for provision and easy access to data-intensive, remotely- 
steerable simulations. 

5.2 NextGrid Architecture for Next Generation Grids 

In comparison to the UniGrids project which evolves the existing UNICORE 
Grid system to a service-oriented one, the NextGRID® project aims for the 
future: The goal is to provide the foundations for the next generation of Grids. 
NextGRID is not a project based on the UNICORE architecture or Grid system 
as-is, but institutions and people involved in the UNICORE development from 
the beginning on contribute expertise and experience to NextGRID. 
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Since it is obvious that there is no such thing as the one and only next 
generation Grid, and experts envisage the co-existence of muhiple Grids with 
well-defined boundaries and access points, NextGRID is going to define a Grid 
architecture which can be seen as building blocks for Grids. It does not only 
provide interoperability by-design between entities which exist within one in- 
stantiation of such an architecture, but it also facilitates the interoperability 
between different Grids developed according to the NextGRID architecture. 

Although developing a Grid one generation ahead, NextGRID is not starting 
from scratch. Properties to incarnate and functions to realize future Grids are 
expertly described in ^^^id These reports frame NextGRID's architec- 
tural development while the Open Grid Services Architecture is going to define 
Grid services and their interactions and does therefore make up a staring point 
for the conceptualization and design of NextGRID. In addition, regarding the 
underlying technology and architectural model, NextGRID propagates the usage 
of Web Services and the adoption of Service-Oriented Achitecture (SOA) 
concepts and models. 

NextGRID focuses on security, economic sustainability, privacy /legacy, scal- 
ability and usability. The following properties have the highest priorities when 
carrying out the following work: 

— Developing an architecture for next generation Grids 

— Implementing and testing prototypes aligned with the concepts and design 
of the NextGRID architecture 

— Creating reference applications which make use of the NextGRID prototypes 

— Facilitating the transition from scientific- to business-oriented Grids by in- 
tegrating the means to negotiate a certain Quality of Service (QoS) level 

— Specifying the methods, processes, and services necessary to dynamically 
operate Grids across multiple organizations which comprise heterogeneous 
resources 

Since the ongoing UNICORE development in projects like UniGrids shares 
resources as well as the technological foundation with NextGRID there is a 
high chance that the outcome of NextGRID will also represent the next step of 
UNICORE's evolution. 

6 Conclusion 

In this paper we presented the evolution of the UNICORE technology from a 
Grid software with prototype character developed in two German projects to a 
full-grown, well-tested, widely used and accepted Grid middleware. UNICORE 
- Uniform Interface to Computing Resources - provides a seamless, secure and 
intuitive access to distributed Grid resources. Although the UNICORE vision 
was already coined in 1997, the then stated goals and objectives of hiding the 
seams of resource usage, incorporating a strong security model, and providing 
an easy to use graphical user interface for scientists and engineers are still valid 



today: to achieve these goals and objectives, UNICORE is designed as a verti- 
cally integrated Grid middleware providing components at all layers of a Grid 
infrastructure, from a graphical user interface down to the interfaces to target 
machines. 

Initially developed in the German projects UNICORE and UNICORE Plus, 
UNICORE was soon established as a promising Grid middleware in several Euro- 
pean projects. In the GRIP project an interoperability layer between UNICORE 
and the Globus Toolkit 2 and 3 was developed to demonstrate the interoperabil- 
ity of independently developed Grid solutions, allowing to build and to demon- 
strate inter-Grid applications from the bio-molecular and meteorological domain. 
In the EUROGRID project, European high performance supercomputing centers 
joined to extend UNICORE with an efhcient data transfer, resource brokerage 
mechanisms, ASP services, application coupling methods, and an interactive 
access. In addition, a Bio-Grid, Metco-Grid, CAE-Grid, and HPC-Grid were es- 
tablished to integrate a variety of application domains. The main objective of the 
OpenMolGRID project is to provide a unified and extensible information-rich 
environment based on UNICORE for solving problems from molecular science 
and engineering. In the VIOLA project a vertically integrated testbed with the 
latest optical network technology is built up. UNICORE is used as the Grid 
middleware for enabling the development and testing of new applications in the 
optical networked testbed, which provides advanced bandwidth management and 
QoS features. 

With these developments UNICORE grew to a software system usable in 
production Grids. In this context UNICORE is deployed in the large German 
supercomputing centers to provide access to their resources. At the John von 
Neumann-Institute for Computing, Research Center Jiilich, many users submit 
their batch jobs through UNICORE to the 1312-processor 8.9 TFlop/s IBM 
p690 cluster and the Cray SVl vector machine. Leading European HPC centers 
joined in the project DEISA to build a distributed European infrastructure for 
scientific applications based on UNICORE to build and operate a distributed 
multi tera-scale supercomputing facility. 

The future of UNICORE is promising and follows the trend of "Everything 
being a Service" by adapting to Open Grid Service Architecture (OGSA) stan- 
dards. In this context, the UniGrids project continues the effort of the GRIP 
project in integrating the Web Services and UNICORE technology to enhance 
UNICORE to an architecture of loosely-coupled components while keeping its 
"end-to-end" nature. To this end UNICORE/GS will be developed, which makes 
UNICORE comphant with the Web Services Resource Framework (WS-RF). 

Today the UNICORE software is available as open source under a BSD li- 
cence from SourceForge for download. This enables the community of core UNI- 
CORE developers to grow and makes future development efforts open to the 
public. 
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